Skunkware 5/Skunkware 5.iso/src/Tools/expect-5.16/FAQ

Text File | 1995-07-14 | 45.7 KB | 1,106 lines

This is the Frequent-Asked-Questions (FAQ) file for Expect

This file represents questions I've received (with answers I've given)
frequently, usually about subjects that don't fit in the man page for
one reason or another.  In some cases, I've left the original
questions.  I suppose I could've stripped off the headers, but it
seems more realistic to see actual people who've asked the questions.
Thanks to everyone who asked.

Rows of hyphens separate the different topics.  In cases where I've
reprinted the original question-letter and my answer, the two are
separated by a short row of hyphens.

The papers listed in the README file should also be consulted for highly
technical or philosophical discussion of the implementation, design and
practical application of Expect.

-Don

Here is a short summary of each question/answer.  You can search for
the number, for example, "#3" once you've found the subject you're
looking for.

#0 I keep hearing about Expect.  So what is it?
#1 Why does expect need to be setuid root on Cray?
#2 Why isn't there an expect mailing list?
#3 How do you pronounce "Ousterhout" anyway?  (Or "Libes" for that matter?)
#5 Can expect automatically generate a script from watching a session?
#6 What do you think about the Perl rewrite of Expect?
#7 Why should I learn yet another language (Tcl) instead of writing my
    interaction in <a language I already know>.
#8 How come I get "ioctl(set): Inappropriate ..., bye recursed" ...
#9 Do we need to pay or ask for permission to distribute Expect?
#10 Can Expect understand screen-oriented (curses) programs?
#11 Why doesn't Expect kill telnet (or other programs) sometimes?
#12 Why is this FAQ so short?
#13 Why can't I send the line "user@hostname\r"?
#14 Does Expect run on VMS?
#15 Why does "talk" fail with "Who are you?  You have no entry utmp" or
    "You don't exist.  Go away".
#16 Why don't the examples in your USENIX papers work?
#17 Why does . match a newline?
#18 Is it possible to use Expect and TclX together?
#19 Is it possible to use Expect and <lots of random extensions> together?
#20 Is it possible to prevent Expect from printing out its interactions?
#21 Why isn't overlay covered in Exploring Expect?
#22 Are you going to have a book signing?
#23 Can you put the examples in your book into an anonymous ftp site?
#24 Is the front cover of your book a self portrait (ha ha)?
#25 Are there any hidden dangers in using Expect?
#26 Compile fails with: Don't know how to make pty_.c
--------------------------------------------------------------------------
#0
To: Charles Hymes <[e-mail]>
Subject: I keep hearing about Expect.  So what is it?
In-Reply-To: <[e-mail]>
References: <[e-mail]>
    <[e-mail]>
--text follows this line--
Charles Hymes writes:
>
>
>So,
>What is  Expect?

Expect is a tool for automating interactive applications such as
telnet, ftp, passwd, fsck, rlogin, tip, etc.  Expect really makes this
stuff trivial.  Expect is described in many articles, papers, and
FAQs.  There is an entire book on it available from O'Reilly.

You can ftp Expect from ftp.cme.nist.gov as pub/expect/expect.tar.Z

Don
----------------------------------------------------------------------
#1
From: libes (Don Libes)
To: [e-mail] (Lori Wong)
Subject: setuid in expect
Date: Thu, 24 Oct 91 16:15:20 EDT

>     I have been running expect now under UNICOS 6.1 and CSOS 1.0 (Cray
>Computer Corporation's OS).  The two machines that I am running expect
>on have stringent security features, one of which is to limit setuid
>privileges to specific individuals.  I was wondering if you would be
>kind enough to explain the purpose of the setuid that is needed by expect
>and whether it could be compiled to run without having to have setuid
>privilege?  I know it has to do with spawning and communicating with
>the various spawned tasks, but don't know enough of the details to be
>able to explain why expect specifically needs setuid and whether or not
>it could cause a security problem (could someone use it to enter into
>the system and wreak havoc, for example?).  Right now, I've limited
>the access of expect to my group, but need to know what the security
>implications are if I open it to all users.  I'd appreciate any light
>you can shed on this subject...

Root-access is needed to open a pty under Unicos.  Thus, all programs
accessing ptys must be setuid root.  If you do an "ls -l" of programs
like "script", "xterm", etc, you'll see this.

I have no idea why this is.  The requirement was probably for security
reasons to begin with, but it has the ironic effect of making more
programs require setuid and therefore greater possibility of errant
setuid programs.

In fact, there is one known Unicos bug relating to the way uids are
switched at exec time which requires further special coding.  If you
search for "Cray" in the Expect source you will see significant chunks
of code to get around the problem.

I don't know if this reassures you any.  All I can tell you is that a
number of Cray experts have looked into the situation and are happy
with the current implementation of Expect.

Don
--------------------------------------------------------------------------
#2
From: libes (Don Libes)
To: [e-mail] (David R. Clark)
Subject: Mailing list for expect
Date: Mon, 23 Sep 91 18:21:28 EDT

>Would be nice if their were an expect mailing list.  I would use it more
>often, and be made aware of other users.

Perhaps I'm too myopic, but I don't see the need for it.  I typically
get two or three expect questions a week, which I answer myself.

For one reason or another (usually a bug fix, but often, just revising
the documentation), I update expect about once every two weeks.
Personally, I'd hate being on the other end of something like this.
Who needs patches every two weeks for problems that probably aren't
even relevant to you?

>It would be helpful, too, if this served as an area for swapping programs.
>Many of the things that I want to do are done by others already.

Send me things that you'd like to distribute.  I'll either include
them with expect or put it in a publicly accessible directory so other
people can get it.  Yes, I know it's not as good as getting notified
via a mailing list, but actually I doubt there's such a need.  The
reality is that most of the programs expect is applied to have
poorly defined interfaces.  There are few portable expect scripts.

For example, you can't even write a guaranteed-portable script that
knows what a shell prompt looks like because everyone customizes them!
And the ftp scripts don't work on everyone's ftp because the ftp user
interface is not specified by the standard, so everyone's is
different.  And so on.

There is a Tcl newsgroup, comp.lang.tcl, which many expect users read.
It's pretty good for asking questions about Tcl, and there isn't that
much traffic that an occasional Expect question isn't looked upon
favorably.  Indeed, some of the sharpest Tcl hackers read the mailing
list, so I post news about new-releases of expect there first.  The
newsgroup is gatewayed to a mailing list ([e-mail])
which is further described in the Tcl documentation.

Don
--------------------------------------------------------------------------
#3
From: [e-mail] (John Ousterhout)
To: [e-mail]
Subject: Re: pronunciation?
Date: Tue, 29 May 90 21:26:10 PDT

Those of us in the family pronounce it "OH-stir-howt", where the
first syllable rhymes with "low", the second with "purr", and the
third with "doubt".  Unfortunately this isn't the correct Dutch
pronounciation for a name spelled this way (someplace along
the line it got misspelled:  it was originally "Oosterhout"), nor
is it what you'd guess if you use common sense.  So, we've gotten
used to responding to almost anything.

                    -John-

I suppose I should say something in kind.  "Libes" is pronounced
"Lee-bus" with stress on the first syllable.  Like John, though, I've
gotten used to responding to anything close. - Don
--------------------------------------------------------------------------
#5
From: libes (Don Libes)
To: [e-mail]
Subject: expect
Date: Fri, 12 Oct 90 17:16:47 EDT

>I like "expect" and am thinking of using it to help automate the
>testing of interactive programs.  It would be useful if expect had a
>"watch me" mode, where it "looks over the shoulder" of the user and
>records his keystrokes for later use in an expect script.
>
>(Red Ryder and other Macintosh telecommunications packages offer this
>sort of thing.  You log onto Compuserve once in "watch me" mode, and
>RR keeps track of the keystrokes/prompts.  When you're done you have a
>script that can be used to log onto Compuserve automatically.)

I'd like to see how they do it.  The major problem is when you type
characters, they are invariably echoed.  So if you "interact" with a
system and type "finger", what expect sees is that
you typed 'f',
computer typed 'f',
you typed 'i',
computer typed 'i',
you typed 'n',
computer typed 'n',
...

I.e. expect has no way of knowing that you weren't waiting to see the
computer say 'f', before you typed 'f'.

You'd have to handle problems like this, kind of guessing if the
computer is echoing or you are really waiting for the response.  The
system actually doesn't echo exactly what you type, making this even
harder.  And there are other problems: sometimes characters get lumped
together rather than sent separately, sometimes echoing is turned off
for you.

If you run expect in debug mode while doing "interact", you'll see
what I mean.

Given that you'd have to do such severe editing of an automatically
produced script, I figure writing the script from scratch is easier.

Actually, I suggest you used the interact facility (or the UNIX script
program) and just edit the output.  Invariably, you want to change a
lot of text to *s and add alternatives (i.e. a lot of editing) anyway.

Do you have to do much editing with scripts that Red Ryder produces?
How does it handle these problems?  Does it support regular
expressions and alternation?  (Obviously, a computer-generated script
can't generate these automatically.)  Do you have to tell it whether
you are full/half-duplex or what kind of line-termination characters
you are using?

Is there anything else in Red Ryder that would be useful in expect?

>Before I look into adding a "watch me" feature, I thought I should
>ask: has this been done already?

You're welcome to give it a shot.  I'd be interested to see what you
come up with.

Don

------------------

From: (Pete TerMaat) <[e-mail]>
To: [e-mail] (Don Libes)
Subject: Re: expect
Date: Thu, 17 Jan 91 12:30:01 -0600

 > >I like "expect" and am thinking of using it to help automate the
 > >testing of interactive programs.  It would be useful if expect had a
 > >"watch me" mode, where it "looks over the shoulder" of the user and
 > >records his keystrokes for later use in an expect script.
 > >
 > >(Red Ryder and other Macintosh telecommunications packages offer this
 > >sort of thing.  You log onto Compuserve once in "watch me" mode, and
 > >RR keeps track of the keystrokes/prompts.  When you're done you have a
 > >script that can be used to log onto Compuserve automatically.)
 >
 > I'd like to see how they do it.  The major problem is when you type
 > characters, they are invariably echoed.

 > You'd have to handle problems like this, kind of guessing if the
 > computer is echoing or you are really waiting for the response.

That appears to be what Red Ryder does.  It works surprisingly well
for line-oriented things.  It produces unnecessarily lengthy (though
still working) scripts when you make a lot of corrections by
backspacing.  And it isn't suitable for character-oriented things like
editors, where there is no notion of a prompt.

 > If you run expect in debug mode while doing "interact", you'll see
 > what I mean.

Ah, thanks for the tip.  I hadn't appreciated the problem.

 > Actually, I suggest you used the interact facility (or the UNIX script
 > program) and just edit the output.  Invariably, you want to change a
 > lot of text to *s and add alternatives (i.e. a lot of editing) anyway.

I'm working with text editors and document viewers, so for every
character typed there can be a lot of output.  It wouldn't make sense
for me to wade through all that output and trim it down.

Writing the scripts from scratch, as you suggested, is currently my
best approach.  I'm also experimenting with a command which logs just
the input.

 > Do you have to do much editing with scripts that Red Ryder produces?

Here's an example from Microphone (another Macintosh communications
program), which is not as sophisticated in its watchme mode as Red
Ryder.  I had it watch me while I typed "echo this is a test" to the
shell.  It's pretty stupid, but (to my surprise) the script
nevertheless works, without any editing.

    6   Wait for Text  "% "
    7   Send Text String  "echo"
    8   Wait for Text  "% ech"
    9   Send Text String  " "
    10  Wait for Text  "echo "
    11  Send Text String  "this"
    12  Wait for Text  "o thi"
    13  Send Text String  " "
    14  Wait for Text  "this "
    15  Send Text String  "is a "
    16  Wait for Text  "is a "
    17  Send Text String  "te"
    18  Wait for Text  " a te"
    19  Send Text String  "st"
    20  Wait for Text  " test"
    21  Send Text String  "^M"
    22  Wait for Line Containing  " test"

Here's an example of the same thing done with Red Ryder watching.
Much better!

    PROMPT %
    PAUSE
    TYPE echo this is a test^M
    PROMPT %

Red Ryder appears to keep track of what was typed and eliminate that
from any possible prompts.  As you pointed out, what was typed is not
always what was printed, but in my experience (mostly using it to dial
up to UNIX sites) this hasn't been a problem.

 > How does it handle these problems?  Does it support regular
 > expressions and alternation?  (Obviously, a computer-generated script
 > can't generate these automatically.)

No, just literals.  Red Ryder won't go back further than the last line
of output, which usually works better than Microphone's more generous
approach.

 > Do you have to tell it whether you are full/half-duplex or what
 > kind of line-termination characters you are using?

Since it's a communications program it already has the info, but I
don't know that it uses this information when it creates the scripts.

 > Is there anything else in Red Ryder that would be useful in expect?

Good question.  I think expect has these programs beat though, with
the exception of a watchme feature.  A visual interface would be nice,
as one thing that I miss from Red Ryder is the status line, which
tells you the current command.  (I know you can sort of simulate this
by tracing the TCL code.)  Some of my expect scripts are long and it's
helpful to know what they are sending/expecting when they pause/hang.
As long as I'm dreaming, it would also be nice if I could single-step
through a script by pressing a "single-step" button.  I guess these
are more TCL issues than expect issues.

Microphone has a nice interface for novices.  You can write a script
with very little typing by pointing and clicking from menus of
keywords.  Red Ryder's language is less verbose and probably more
powerful, but neither is as powerful/flexible as expect/TCL.

 > >Before I look into adding a "watch me" feature, I thought I should
 > >ask: has this been done already?
 >
 > You're welcome to give it a shot.  I'd be interested to see what you
 > come up with.

Since it's not quite so useful for character-oriented editors as for
line-oriented things, I've decided for now just to write the scripts
from scratch.

I'll say again that I like the tool a lot--nice work!  There are other
people here using it for things like the testing of ksh, which
responds differently to signals when not used interactively.

I have some mods to make expect run on a Cray.  I was sort of waiting
to see if the mods are Cray-specific or System V specific before
forwarding them, but if you would like to incorporate them right away
I will send them.

-- Pete

--------------------------------------------------------------------------
#6
From: [e-mail] (Don Libes)
Subject: Re: Expect.pl, alpha release
Date: 2 Nov 90 03:06:40 GMT

In article <[e-mail]> [e-mail] (Randal Schwartz) writes:
>The motivation for writing this package is the fact
>that Don Libes doesn't like Perl. :-)

I've never said anything like that, nor is it true (although I will admit
that I've had a lot of trouble learning Perl.)  Fact is, I've written
several Perl hacks, at least one of which is used daily at my site.

>The matchup of expect<->tcl and expect.pl<->Perl made for some weird
>design tradeoffs.  I may start from mostly scratch and do everything
>right.  That is probably why I hesitate to implement the rest of the
>functions... they really don't fit in a Perl environment.

Actually, I discussed these issues with several people during the
development of expect.  The approach I took effectively sealed off the
user from the underlying C implementation, substituting the more shell-
like Tcl language and reducing the ability to screw themselves somehow.

In the approach you took, the user language IS Perl, which provides
incredible power and flexibility.  The primary disadvantage is that
the user may have to learn Perl, which is hard.

Also, as you noticed, some of the features (like logging) are a problem
for Perl.  Oh, and as you suspected, recursive invocations are useful -
consider writing scripts that are half automated and half interactive,
like the fsck script I showed at the LISA conference.

Please don't get me wrong.  I think Perl is very useful.  I desperately
want a copy of your book.  And I consider it a compliment that you
followed my implementation as faithfully as you did.  Though, I did
think some of your Perl code pretty weird!

Actually, in my USENIX paper I stated that I fully expected someone to
incorporate the expect primitives into a shell, Perl, whatever.  I was
just showing proof of concept.  It just happened to turn out to be
worth keeping around.

In fact, I owe a lot for it to John Ousterhout who wrote Tcl.

Don Libes          [e-mail]      ...!uunet!cme-durer!libes
------------------
Article 10362 in comp.lang.perl:
From: [e-mail] (Randal L. Schwartz)
Subject: Re: perl4.035 & Solaris2.1 & sockets problem
Message-ID: <[e-mail]>
Date: 18 Feb 93 16:01:26 GMT
References: <[e-mail]> <[e-mail]>
Organization: Stonehenge Consulting Services; Portland, Oregon, USA
Lines: 26
In-Reply-To: dnoble@hobbs's message of 17 Feb 93 22:14:30 GMT

>>>>> In article <[e-mail]>, dnoble@hobbs (David Noble) writes:
David> Check to see if 'sys/socket.ph' is required by the script. If it's not
David> there, the script may have hard-coded some constants that are different
David> under Solaris. Reminds me of some code in chat2.pl:
David>         unless (socket(S, 2, 1, 6)) {
David>                 # XXX hardwired $AF_SOCKET, $SOCK_STREAM, 'tcp'
David>                 # but who the heck would change these anyway? (:-)

Yup.  I've been bitten by this code (*my* code) myself when I moved to
a blecchy sysV environment.

All because I had used chat2 on only the few boxes (all BSD-derived)
that I had access to at the time, and I was too lazy to run h2ph. :-)

*Someday* soon, after the 5.0 camel update, and Learning Perl hits the
stands, I'm going to rewrite the chat2 stuff to make it portable, add
some documentation, and then release it (finally!) as a Beta release.
(It's still just an alpha, folks!  Enough stuff to make it work for
*my* needs, but not really meant as a general tool yet!... sigh.)

print "Just another Perl [book and class, but not lib code :-] hacker,"
--
Randal L. Schwartz
--------------------------------------------------------------------------
#7
From: libes (Don Libes)
To: Aamod Sane <[e-mail]>
Cc: libes
Subject: Re: Expect, Tcl, programmed dialogue etc.
Date: Mon, 2 Sep 91 15:47:14 EDT

>    >>A friend told me about "expect". But then, I have to know the
>    >>idiocies of "tcl". I would like to know if there is an alternative
>    >>to expect that is also useful in other places, so that I do not
>    >>have to spend time getting used to tcl for just this one tool.
>
>    Your reasoning is shortsighted.  Tcl is a language that can be used in
>    other applications.  It won't be a waste of your time to learn it.
>
>I have nothing against tcl as such.
>The reluctance to learn it comes mainly from the feeling that half my
>life seems to be spent learning new languages that differ very little
>from existing ones, and differ in annoying little details at that.
>To add to the misery, every implementation has its own
>idiosyncracies...:-(

Ironically, Tcl was written specifically to halt this very problem.

The author recognized that every utility seems to have its own
idiosyncratic .rc file or programming language.  Tcl was designed as a
general-purpose language that could be included with any utility, to
avoid having everyone hack up their own new language.

In this context, your statements to the newsgroup do Tcl a great
disservice.

Don
------------------------------------------------------------------------
#8
From: [e-mail] (James B. Davis)
To: [e-mail]
Subject: How come I get "ioctl(set): Inappropriate ..., bye recursed" ...
Date: Tue, 10 Dec 91 10:47:21 MST

Every time I ^C out of a expect script run I get:

ioctl(set): Inappropriate ioctl for device
bye recursed

Is this standard or am I doing something wrong?

[e-mail]
---------------
From: Michael Grant <[e-mail]>
Subject: Re: How come I get "ioctl(set): Inappropriate ..., bye recursed" ...
Date: Tue, 10 Dec 91 16:05:01 EST

The problem was that I hadn't run the fixincludes shellscript and
recompiled gcc with itself during gcc installation.  I recompiled gcc
with itself, then ran the fixincludes script, the messages went away.

Michael Grant

--------------------------------------------------------------------------
#9
From: libes (Don Libes)
To: Mohammad Reza Jahanbin <[e-mail]>
Subject: Copyright Question.
Date: Tue, 26 Jan 93 23:46:24 EST

Mohammad Reza Jahanbin writes:
>Before anything let me thank you on behalf of ComputeVision R&D for
>putting so much effort into expect. Part of CV has been using expect
>for the past two years or so to build variety of tools including an
>automated testbed for a product.
>
>CV is currently considering shipping the automated testbed to some of its
>retailers, to enable them to perform their own tests before distributing
>the product.
>
>The Question is, are we allowed to ship expect? Do we need to ask
>anyone for permission? Do we need to say or write anything in the
>documentation? Do we need to pay for it?
>
>I have not been able to find any copyright (or indeed copyleft) notices
>in the usual expect distribution. Would you be able to clarify our position.

Sorry to delay in responding.  I sent your request to my management
and they had to discuss it (if they didn't, there would be no reason
to pay them).  While they continue to discuss it, I can tell you
informally the gist of what they will eventually say:

You are allowed to do just about anything with Expect.  You can even
sell it.  You need not ask our permission.  You need not pay for it.
(It is my understanding that your tax dollars, in effect, already have
paid for it.)

You cannot claim that you wrote it (since this would be a lie), nor
can you attempt to copyright it (this would be fruitless as it is a
work of the US government and therefore not subject to copyright).

NIST would appreciate any credit you can give for this work.  One line
may suffice (as far as I'm concerned) although there should be
something to the effect that this software was produced for research
purposes.  No warantee, guarantee, liability is implied.

My management would appreciate it if you sent a letter on your company
letterhead suitably praising Expect and briefly describing how it has
helped your business.  Send this to the following individuals:

Arati Prabhakar, Director
NIST
Admin Bldg, Rm A-1134
Gaithersburg, MD 20899

Mike Wozny, Manufacturing Engineering Laboratory
NIST
Bldg 220, Rm B-322
Gaithersburg, MD 20899

Howard Bloom, Manufacturing Systems Integration Division
NIST
Bldg 220, Rm A-127
Gaithersburg, MD 20899

Steve Ray, Information Dissemination Group
NIST
Bldg 220, Rm A-127
Gaithersburg, MD 20899

In case you're wondering about the uninformative titles, Arati is the
directory of all of NIST (about 3000 people) and Steve (way down there
at the bottom) is my immediate supervisor (and of 7 other people).

If you feel more indebted than a letter can express, your company can
sign a CRADA (Cooperative Research and Development Agreement) with
NIST.  This is a contract that can be customized as you like.
Typically, CRADA's state that we give you explicit permission to
distribute or commercialize our code, and that we are willing not to
divulge any company secrets you tell us.  CRADA's can also state
that we will share further developments with you, or that you are
giving us money or software, or even just sending us bugs, fixes and
experiences.

These contracts are looked upon by Congress as an indication that we
are helping American industry (i.e., doing our job).  Even though they
seem vague and almost pointless, they essentially are brownie points
for NIST when it comes to asking for funding from Congress each year.

I hope this has answered your questions.  Let me know if you have
further questions.

Don
----------------------------------------------------------------------
#10 Can Expect understand screen-oriented (curses) programs?

I wrote a script called "term_expect" which uses a Tk text widget to
support screen-oriented expect commands.  This is described further in
Chapter 19 of Exploring Expect.  The code is in Expect's example
directory.

Adrian Mariano <[e-mail]> converted the term_expect code
(see above) so that it runs without Tk (exercise 4 in Chapter 19!)
This is available in the example directory as "virterm".

Mark Weissman ([e-mail]) and Christopher Matheus modified a
version of Expect so that it has a built-in Curses emulator.  It can
be ftp'd from the Tcl archive as expecTerm1.0beta.tar.Z.  Note that
Expecterm does not run with the current version of Expect.  On the
other hand, if you are interested in doing some development and
porting work, let me know.  While I'm still gathering ideas, I suspect
that ultimately I would like to take the ideas of term_expect and the
implementation approach of Expecterm.

----------------------------------------------------------------------
#11 Why doesn't Expect kill telnet (or other programs) sometimes?

To: [e-mail]
Subject: Re: need help running telnet expect script from cron on sunos 4.1.3
--text follows this line--
[e-mail] writes:
>       The only problem I am still having with the script I wrote is that
>    the telnet does not seem to die on it's own, unless I turn on debugging.

Actually, Expect doesn't explicitly kill processes at all.  Generally,
processes kill themselves after reading EOF on input.  So it just seems
like Expect kills all of its children.

>    I was forced to save the pid of the spawned telnet, and kill it with an
>    'exec kill $pid' in a proc that is hopefully called before the script
>    exits. This seems to work fine, but it makes me nervous since omnet
>    charges for connect time, and leaving a hung telnet lying around could
>    get expensive. I warned the rest of the staff so that they will also be
>    on the lookout for any possible hung telnets to omnet.

The problem is that telnet is not recognizing EOF.  (This is quite
understandable since real users can't actually generate one from the
telnet user interface.)  The solution is to either 1) explicitly drive
telnet to kill itself (i.e., a graceful logout) followed by "expect
eof" or 2) "exec kill" as you are doing.

Don
----------------------------------------------------------------------
#12
To: Wade Holst <[e-mail]>
In-reply-to: <[e-mail]>
Subject: Expect question
--text follows this line--
Wade Holst writes:
>
>For version 5.5, running on sparc with SunOS 4.1.3
>
> 1) Is there a more up-to-date version of the FAQ than what
>    comes with expect-5.5?  (For such a useful application, I
>    would expect more than 12 questions).

Funny you should ask that because it's been on my mind lately and no
one else has asked.  I know a lot of other packages have huge FAQs but
I have always believed that this is an indication that their man pages
suck.  By comparison, the stuff in the Expect FAQ is only the stuff
that just doesn't belong in the man page.

On the other hand, I've recently seen some really well-written FAQs -
they duplicate some material but they are organized so well that
they're a pleasure to use.  So I guess I'm changing my mind on FAQs.
I just haven't had the time to make one.

I've actually been working on a real book on Expect.  It answers
all of the questions I get  - unfortunately it is 400+ pages.  So it's
not very appropriate for an FAQ either!  It should be out in the
second half of '94.
----------------------------------------------------------------------
#13
To: [e-mail]
Subject: Re: [Q] expect, ftp and '@'
--text follows this line--
>   I am attempting to use expect to perform anonymous ftp gets without
>my having to type all the stuff --- I mean, waaaiiiting for the
>prompt, entering a-n-o-n-y-m-o-u-s with my fat fingers, and the rest.
>
>   But I have a probleme: as I set the password to be my e-mail address:
>   set password "[e-mail]"

> the ftp servers seem not to receive neither my login name nor the
>at-sign. Some of them do not care, some others say "ok, but don't do
>that again", and the last ones throw me off.

spawn initializes the terminal using your current parameters and then
forces them to be "sane".  Unfortunately, on your system "sane" says
to interprete the "@" as the line-kill character.

The most sensible thing to do is change "sane" in your Makefile to
something that makes sense.  (Since you work at HP, you might also
suggest that they modernize stty!)

Other alternatives are: quote the @, or use the -nottyinit flag, or
set the stty_init variable.

Don

--------------------------------------------------------------------------
#14
To: Cameron Laird <[e-mail]>
Subject: VMS question.
In-Reply-To: <[e-mail]>
References: <[e-mail]>
--text follows this line--
Cameron Laird writes:
>Do you know of anyone working with expect and VMS?
>I'd like not to re-invent wheels, but, if I'm to be
>the first one, I want others to benefit.

No, I'm not aware of anyone doing it.  Since VMS claims POSIX
conformance, it shouldn't be that hard - Expect uses the POSIX calls
if it can.  Probably the hardest part will just be modifying the Makefile
and the configure script!

Note however, that there might be a simpler solution.  The neat thing
about Expect is that you can control other computers easily.  Run
Expect on your UNIX box and have it log in to the VMS box and do its
thing.  (You can bypass the login garbage by using an inet daemon.)
We've done exactly this to a number of weird pieces of hardware we
have around the lab (robots, Lisp machines, embedded controllers, and,
of course, a VAX running VMS).  It saves time porting!

Don
----------------------------------------------------------------------
#15
To: Will Smith (AC) <[e-mail]>
In-reply-to: <[e-mail]>
Subject: expect
--text follows this line--
Will Smith (AC) writes:
>Hi there.  I was wondering if you had any ideas to why i am getting
>this problem running an expect script which tries to spawn a talk
>process to myself on another machine. Would it have anything to do
>with the fact that the executables are NOT installed in /usr/local/bin
>or because it wasnt installed by ROOT or what. This is what my expect
>script looks like.
>
>#! /home/ritchie/ops/william/test/expect -f
>
>spawn talk [e-mail]
>set timeout 200
>expect {*established*}
>set send_human {.1 .3 1 .05 2}
>send -h "This is only a test.. I swear \ Please don't bust me with expect \n \
>expect "{*\r*}"
>expect "{*\r*}"
>exec sleep 5
>send -h "Ok, well see ya tomorrow you idiot \n"
>exec sleep 3
>
>The error i get is that it returns this when i run the script.
>
>  Who are you? You have no entry in /etc/utmp! Aborting...

On most systems, Expect does not automatically make a utmp entry.  (A
utmp entry normally indicates login information which seems kind of
pointless for Expect scripts.)  This allows Expect to run non-setuid.

Normally, this lack of utmp entries doesn't mean much.  However, a few
programs actually refuse to run without a utmp entry.  Fortunately,
there are workarounds:

Program-dependent solutions:

"talk" is the only program I'm aware of that falls into this category.
One solution is to get ytalk.  ytalk doesn't have this problem plus it
fixes many other bugs in talk, such as being able to communicate with
both old and new talk.

Program-independent solutions:

Use a program specifically intended to create utmp entries.  Such
programs are easy to write or get if you don't have them already.  For
instance, sessreg is one which comes with the xdm distribution.  I
like this approach because it isolates the setuid code in a small
single system utility rather than in every program on the system that
needs this ability.

Don
--------------------------------------------------------------------------
#16
To: Will Smith (AC) <[e-mail]>
Subject: expect
--text follows this line--
Will Smith (AC) writes:
>I just entered some scripts from a USENIX paper that my boss had.  I get
>errors about my quotes in the script.  Also, it doesn't seem to know
>about expect_match.  Thanks in advance for any insight you could offer.

The USENIX papers are old and out-of-date as far as quoting goes.  A
couple years ago, I cleaned up and simplified this aspect of Expect.
Similarly, expect_out is now where the results of expect's pattern
matching are saved.

The man page is always the best reference on what Expect currently
supports.  Alternatively, you can read the CHANGES files.  These files
document the changes from one major version to another.

Don
--------------------------------------------------------------------------
#17 Why does . match a newline?
To: [e-mail] (Ivan Prochazka)
Subject: Why does . match a newline?
Ivan Prochazka writes:
>
>Hello Don.
>
>In my opinion(and emacs) the regexp-symbol "." stands for all
>characters except newline(\n).
>This is not the case in expect 5.2.

Yes, there are some packages that follow this convention, but I don't
think it is appropriate for Expect.  Unlike emacs, most Expect
patterns don't look for full lines - more often they look for prompts
which *don't* end with newlines.  I find that I actually write the
\[^\n] pattern very rarely.  And if I write it frequently in a script,
then the expect itself probably ought to be in a subroutine.

In fact, the more common line terminating sequence in Expect is \r\n,
so that might make a more likely argument.  In any case, Expect
defines . the way POSIX does.  So I feel pretty good about the
definition of . being what it is.

Don
--------------------------------------------------------------------------
#18 Is it possible to use Expect and TclX together?
From: [e-mail] (Bob Friesenhahn)
Date: 20 Jul 1994 04:09:43 GMT
Organization: Interphase Corporation, Dallas TX - USA

Jeffery A. Echtenkamp ([e-mail]) wrote:
: Do expect and tclX work together? If so, must anything special be done to
: get them to work together?

They work fine together.  However, you should pre-pend "exp_" to your expect
command names.  This will ensure that there are no conflicts between expect
commands and tclX commands of the same name (like wait).

Just pick up the "make-a-wish" package, follow the instructions, and you will
be all set.  I have built a wish based on tcl, tk, expect, tclX, and dp using
this technique with no observed problems.

Bob
---
Bob Friesenhahn, Interphase
[e-mail]
--------------------------------------------------------------------------
#19 Is it possible to use Expect and <lots of random extensions> together?
To: Frank Winkler <[e-mail]>
Subject: Q expect + TkSteal
In-Reply-To: <[e-mail]>
References: <[e-mail]>
--text follows this line--
Frank Winkler writes:
>Hi don,
>
>a short question considering installation of expectk.
>
>Is it possible to build an expectk-binary, which uses
>the features of BLT, TkSteal and expect ?

I've never done it, but I know it must be possible because the tgdb
package in the Tcl archive uses all of those extensions with Expect.

Expect is a "well-behaved extension" in the sense that it requires no
changes to the Tcl core.  So Expect should work with any other Tcl
extensions.  You just need to add the usual Exp_Init call to main() or
the other _Init calls to Expect's main.

>If yes, which of them should be build first, second ... ?

Order doesn't matter.

I've done this kind of thing by hand.  It's pretty simple.  But people
tell me the make-a-wish package in the Tcl archive automates the
creation of multi-extension Tcl applications.

Don
----------------------------------------------------------------------
#20 Is it possible to prevent Expect from printing out its interactions?
To: Sunanda Iyengar <[e-mail]>
Subject: Disabling display from expect
In-Reply-To: <[e-mail]>
References: <[e-mail]>
    <[e-mail]>
--text follows this line--
Sunanda Iyengar writes:
>Is it possible to have expect interact with a process and not print-out
>the results of interaction? In my application, I need it to go into a
>silent mode, communicate with a process without reporting to the user, and
>then come back to normal mode and  put the process into interactive mode.

Use the following command:

    log_user 0

To restore output:

    log_user 1

See the Expect man page for more details or page 175 of Exploring
Expect for details and examples.

Don
----------------------------------------------------------------------
#21 Why isn't overlay covered in Exploring Expect?

To: [e-mail]
Subject: Your book
In-Reply-To: <[e-mail]>
References: <[e-mail]>
--text follows this line--
Gene Spafford writes:
>I'm curious as to why the "overlay" command is not mentioned anywhere
>in the book.  Is that a recent addition?  A deprecated feature?  I
>ended up using it in one of my scripts....

The overlay command has been in Expect for a long time.  In all that
time no one has ever asked me about it and I have never used it.
Well, I used it once but I really didn't like the result, and so I
rewrote the script to not use it.  I left the overlay command in
Expect because it seemed like an interesting idea, but I never really
finished it - in the sense that I believe it needs some more options
and controls.  In comparison, the interact command is very flexible
and makes the need for overlay pretty moot.

--------------------------------------------------------------------------
#22 Are you going to have a book signing?

To: Josef Sachs <[e-mail]>
Subject: expect
--text follows this line--
Josef Sachs writes:
>Do you have any book-signing sessions planned?

That's very ego-boosting to contemplate but I doubt that my name/book
is enough to draw the kind of crowd that would make it worthwhile.
I'll leave that kind of thing to Howard Stern.  Anyway, I have a
full-time job working for the government.  I doubt they would take too
kindly to me taking time off for self-aggrandizing.  (They weren't
particularly encouraging to have me write a book in the first place -
as you'll read in the Preface.)

I've written a couple of other books and people have mailed me those
for signatures.  (One guy sent me an entire box of books for
signatures - he was giving them to friends as Christmas gifts.)  If
you're similarly inclined, my address is in Expect's README file.  Or
if you're ever in my neck of the woods, feel free to stop by for a
chat (and bring your copy).

Don

----------------------------------------------------------------------
#23 Can you put the examples in your book into an anonymous ftp site?

To: [e-mail]
Subject: Examples in your book "exploring Expect"
In-Reply-To: <[e-mail]>
References: <[e-mail]>
--text follows this line--
Peifong Ren writes:
>
>Hi,
>
>I bought your book "Exploring Expect" from O'Reilly.
>I wonder can you put the eamples in your book into an anonymous ftp
>site?

All of the substantive examples come with recent versions of Expect.
Just look in the example directory.

Don
----------------------------------------------------------------------
#24 Is the front cover of your book a self portrait (ha ha)?

To: [e-mail] (kinzelman_paul)
Subject: the cover?
In-Reply-To: <[e-mail]>
References: <[e-mail]>
--text follows this line--
kinzelman paul writes:
>The book finally came in. I tried to buy 4 copies but they had only 2
>left and they came in last Saturday. Move over Stephen King! :-)

4 copies!?  Wow.  That's more than my mother bought!

>I was discussing your book with somebody who stopped in and we began
>to speculate about the monkey on the cover. I don't suppose it's a
>self portrait? :-)

There is some real humor here.  There seems to be considerable debate
over what the creature is!  The colophon at the end of the book says
that it is a chimpanzee.  I like that idea much more than a monkey
which is what it looks like to me.  My wife, who has a degree in
zoology, explained to me that chimps are actually the smartest of
primates after man.  Chimps are very intelligent and can do many
things (but not everything) that humans do.  Perfect for describing
Expect.  Anyway, she says I should be honored to have it grace the
cover of the book - even in theory.

I remarked to Edie (the cover designer at O'Reilly) that even though
the cover was nice looking, everyone was going to stare at it and say,
"Gee, but it looks like a monkey."  She replied "The purpose of the
cover is just to get people to pick the book up. This cover will do
that. Don't worry. If you get any rude comments from anyone, at least
you know they are paying attention."

Don
--------------------------------------------------------------------------
#25 Are there any hidden dangers in using Expect?

From: Charlton Henry Harrison <[e-mail]>
To: [e-mail]
Date: Fri, 27 Jan 1995 23:30:56 -0600

>>>Dear Don:
>>>
>>>    I've been a fan of expect ever since I first learned of UNIX back
>>>in late '93. I'm young and don't have my CS degree just yet, but I worked
>>>a while back at Texas Instruments in their Telecom Customer Support dept.
>>>I started in late '93 (and hence, that's where I first started exploring
>>>the UNIX environment) and immediately forsaw the need of automating a lot
>>>of my redundant and mindless duties, but I didn't know how since we were
>>>working over a heterogeneous LAN with multiple OSs.
>>>    Then I found out about expect. I automated everything! My boss didn't
>>>like hearing that I was working on something else in order to get out of
>>>work, and I got tired of explaining it to him.
>>>    Although I accomplished all the aspects of my duties, I was infamous
>>>for being the laziest person at work, and it showed (I made my job SO easy).
>>>I got a new boss after a while, and he hated me from the start and fired
>>>me soon after. Oh well, I guess my mentality didn't click with theirs.
>>>    There are a lot of people like that: they believe life is putting
>>>in a hard day's work to get by. I hate that.
>>>    So the point is, thank you for the wonderful 'expect'. I bought
>>>your book and now I have the most recent version of it on my Linux system
>>>at home. Needless to say I'm looking for another job, though.
>>>
>>>                            Charlton
>>>
>> Thanks very much for your nice letter.  Sorry to hear about your
>> automating yourself out of a job.  Actually, I think most computer
>> scientists have to face this dilemma.  In some ways, it's a
>> self-defeating occupation.
>>
>> Don
>
>Yeah, I'd be interested in hearing if you have a personal philosophy on
>how to handle this kind of thing. I plan on pursuing a career in Artificial
>Intelligence for similar reason of making life easier for everyone (me
>in particular!)  What the future holds in this category is a great
>mystery.

I'm glad you asked.  My personal philosophy on this kind of thing is:
Find someone really rich and marry them.

Don
--------------------------------------------------------------------------
#26
To: [e-mail]
Subject: Compile fails with: Don't know how to make pty_.c
--text follows this line--
You wrote:
   I'm trying to compile Expect on hpux 9.01,
   downloaded from ftp.cme.nist.gov expect.tar

   after running config
   the make fails with  "Don't know how to make pty_.c. (compile fails)
   I see three versions pty_sgttyb.c, pty_termios.c and pty_unicos.c in
   the load, but the configure picked none of them.
   I tried forcing to pty_termios.c but that failed with other compile errors.

I've seen this happen because gcc was partially installed.  configure
finds the gcc stub and uses gcc for all the tests.  But because the
compiler doesn't work, every test fails so configure doesn't select
any of the choices.

So either finish installing gcc or delete the stub.

(And if it's not that, then something similar is wrong with whatever
compiler you've got.  Look closely at the output from configure, it
will tell you what compiler it is trying to use.)

By the way, Expect compiles fine on my HP (A.09.05 E 9000/735).

Don